The term “workflow” or “provisioning workflow” denotes a defined set of provisioning tasks that must be carried out, to configure network resources for a given communication network service or function. A workflow in electronic form comprises a record, which generically means a file, message or other data structure that lists or enumerates the provisioning tasks included in the workflow. Where provisioning is automated, i.e., carried out by one or more nodes or other entities within the communication network, a workflow may be understood as the scripting or programmatic enumeration of tasks, to be carried out by, or at least initiated by, the entities responsible for parsing the workflow.
Commonly, there is some interdependency between certain ones of the tasks comprising a given workflow. For example, one task may depend on the results of another task, meaning that the other task must be performed first. Sometimes there are longer chains of dependencies, where a series of tasks depends on the results of one or more preceding tasks. Indeed, the typical workflow may be represented as a “tree diagram” or other hierarchical graph, where individual provisioning tasks are represented as nodes, which are hierarchically arranged at different levels in the diagram and interconnected according to one or more execution paths that are defined by the applicable task interdependencies.
Generally, however, there is some degree of freedom with respect to task execution. For example, multiple independent tasks within a defined workflow can be performed in arbitrary order, if all other things are equal. The ordering freedom generally increases as the number of tasks within a workflow increases, particularly when the workflow includes multiple independent tasks at one or more hierarchical levels, e.g., multiple independent tasks at a given node level within the workflow tree and/or multiple independent execution paths or branches within the tree.
However, for a number of reasons, including combinational complexity and, at least heretofore, a lack of appropriate metrics or parameters for making optimal task ordering decisions, workflows generally are predefined and executed according to some default, non-optimized task ordering. It is recognized herein that default task ordering can have a high “cost,” where cost can be measured in a number of ways, such as cost in terms of wasted network signaling, and/or wasted computational cycles.
Additionally, it is recognized herein that the process of task ordering is complicated by the possible presence of tasks within a given workflow that cannot be “rolled back.” A task that cannot be rolled back is one that, if it fails and must be repeated, so too must all of its preceding tasks, or at least all preceding tasks lying along its execution path within the task tree must be performed again.